Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @withoutboats (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

However, these buffers aren't actually modified on sendmsg

How do you know this is true? Isn't it up to the implementation?

I don't know how to directly prove that sendmsg does not change the buffers. But generally, syscalls don't modify buffers unless it is written explicitly.

write_vectored has a similar problem. It receives non-mutable IoSlices and casts them to struct iovec, which (in C) contains a non-const data pointer (iov_base). Based on C constness, the kernel could modify these buffers. How it was proven the buffers aren't modified there?

Oh I see - the syscall accepts a const pointer, but the struct itself contains a mutable pointer, which is part of the type definition, not the function signature. Hmm, that makes sense - C doesn't have tools for saying "this pointer is only mut when the struct is".

I'm not 100% comfortable with changing the cast (since it's better to err on the side of caution when dealing with UB) but I won't block it if someone else approves.

If we can't figure out the semantics of sendmsg here, how can we expect the users of this function to figure them out themselves? Rust should expose a safe API with clear semantics. Either specify that the buffers are unchanged (by making the reference non-mutable, this PR) or specify explicitly that the buffers may be overwritten during send and should be rewritten before sending or reading them again. There is no reason to assume that buffers are overwritten during send, so the first option is preferable. If we don't do the cast here, users may do it in their code which needs unsafe again and is more difficult to track if this assumption turns out to be wrong.

For example, the fd-queue crate can be ported to send_vectored_with_ancillary calls (instead of the unsafe manual sendmsg that is used now). Then, write_vectored calls need to be mapped to send_vectored_with_ancillary calls. Without this PR, fd-queue will need to decide whether to cast or to copy the buffers.

Additionally, if the kernel was allowed to overwrite the buffer with arbitrary data, could send_vectored_with_ancillary be a safe function?

@lukaslihotzki any updates?

I have asked a question on Stack Overflow.

Ping from triage
@lukaslihotzki - can you please post your status on this CR. Thank you.

@rustbot label: -S-waiting-on-review +S-waiting-on-author

@lukaslihotzki Closing this due to inactivity. If you find a way how to resolve this, feel free to open a new pull request and we can move it forward from there. Thanks for taking the time to contribute.